Performance Optimization
This weekend, I did some performance testing with ConcurrentLinkedQueue. Then, based on work requirements, I programmed a concurrent primitive array of fixed size, more or less like this:
package com.marcusbiel.javacourse; import java.util.concurrent.atomic.AtomicInteger; public class ConcurrentArray { private static final int MAX_ELEMENTS = 200; private static final Integer[] queue = new Integer[MAX_ELEMENTS]; private static final AtomicInteger pointer = new AtomicInteger(); public static Integer next() { if (pointer.incrementAndGet() > queue.length) { return null; } return queue[pointer.intValue()]; } public static void initQueue() { for (int i = 0; i < queue.length; i++) { queue[i] = Integer.valueOf(i); } } }
Performance Test
Further performance tests revealed that it should be about 10% faster than a ConcurrentLinkedQueue. However, when I tried out a more sophisticated version storing and working on about 400,000 of more sophisticated, complex business Objects – here, it turned out my version had pretty much the same performance than ConcurrentLinkedQueue – while, unlike ConcurrentLinkedQueue, my version is only of static size and not type safe.
This taught me two things:
- Never ever guess performance. Always test it. And test it as close as possible to the exact scenario, in which you will use it in production. I have read and heard this often before, but only when you see the difference for yourself, you realize how much of a difference a theory can make to practice.
- Even if something IS faster, this must not necessarily be the deciding factor. Things done seldom won’t cost much performance, even when you use a very bad algorithm. Only when done repetitive ( for a major part of a computation), it may make a difference (but also here – this must be tested thoroughly of course!). How does a performance difference of 20 ms hurt (e.g, for saving 100 objects) if the overall computation costs you 10 seconds for each iteration?